Guard against invalid `cmsg_len` values while accessing control
messages in ancillary data. This is achieved by checking there is
enough space between the current control message and the end of the
buffer to hold both the current control message and the next one.

This change sync the implementation of `ppm_cmsg_nxthdr()` with the
current glibc implementation:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/cmsg_nxthdr.c;h=0e602a16053ed6742ea1556d75de8540e49157f1;hb=170550da27f68a08589e91b541883dcc58dee640

Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>

Signed-off-by: Roberto Scolaro <roberto.scolaro21@gmail.com>

Signed-off-by: irozzo-1A <iacopo@sysdig.com>

Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>

Optimization for scanning, filter out those file descriptors that are
not socket fds.

Introduce the interesting_subsys set to configure which cgroup
subsystems are going to be considered in set_cgroups.

Signed-off-by: Matthew Knight <matthew.knight@sysdig.com>

Signed-off-by: Matthew Knight <matthew.knight@sysdig.com>

Signed-off-by: Afsan Hossain <84701952+mdafsanhossain@users.noreply.github.com>

Allow to log ASSERT failure instead of hard stopping on it. The change
also enables ASSERT logging in the Release mode on debug logging level
to give more information when troubleshooting.

Experiment with disabling trusted exepath to verify stackrox tests

There is an unexpected difference betweek kernels compiled with gcc and
clang. The former one doesn't support rcu attributes yet, meaning that
READ_TASK_FIELD_INFO on task->cred produces PTR_TO_BTF_ID. The latter
one does support rcu attribute, and READ_TASK_FIELD_INFO ends up with
PTR_TO_BTF_ID | MEM_RCU | MAYBE_NULL [1]. COS seems to be using clang to
compile the kernel:

    # from /boot/config
    CONFIG_CC_VERSION_TEXT="Chromium OS 16.0_pre484197_p20230405-r12 clang version 16.0.0
    (/var/tmp/portage/sys-devel/llvm-16.0_pre484197_p20230405-r12/work/llvm-16.0_pre484197_p20230405/clang 2916b99182752b1aece8cc4479d8d6a20b5e02da)"

The verifier doesn't like the
null part, and to fix it we need to break a chain of reading and verify
that the cred structure is not null.

[1]: https://lore.kernel.org/bpf/20230228040121.94253-3-alexei.starovoitov@gmail.com/

Along the way silence compiler warnings about task_cred

* Adapt the modern probe to clang 21

The code generated by clang 21 is more 'complex' and reaches
1000000 instructions on execve().

* Force casting size(r2) parameter to bpf_probe_read_user()

...otherwise, the compiler thinks that the calling convention allows
to optimize unsigned truncation, a the verifier disagrees.

* Decrease MAX_IOVCNT to satisfy the verifier on rhel

The COS verifier fix broke cred pointer chains using
READ_TASK_FIELD_INTO, which generates 2 CO-RE relocation branches per
call for the bpf_get_current_task_btf existence check. With 8 such
calls inlined into t1_execve_x, this added 16 CO-RE branches causing
BPF verifier state explosion on RHEL 9.4 kernels.

Switch to BPF_CORE_READ_INTO which still breaks the pointer chain (as
COS requires) but without the CO-RE branching overhead. This brings
the branch count back in line with upstream.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Two fixes:

1. Mask ret with & 0xFFFF when assigning to snaplen in 12 BPF programs.
   The verifier on older kernels (RHEL 8 4.18, COS 6.6) rejects
   bpf_probe_read_user calls where the size argument (ret) could be
   negative. The mask tells the verifier the value is bounded unsigned.

2. Stub out t1_execve_x and t2_execve_x with #if 0 around their bodies.
   These tail calls are unreachable since execve_x returns early for both
   success and failure cases (ROX-31971). Their complexity exceeded the
   1M instruction verifier limit on RHEL SAP 9.4 (kernel 5.14.0-427).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>